home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / CIS_GAME.ARJ / QFOFX1.THD < prev    next >
Text File  |  1993-07-01  |  55KB  |  1,117 lines

  1. _________________________ Subj: Flights of Fantasy _________________________
  2.  
  3. Fm: Mitchell Waite 75146,3515                  # 332701 
  4. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 13-Apr-93  11:19:14
  5.  
  6. Today fractal landscapes in Rescue on Fractalus are pretty poor when compared
  7. to Comanche as far as realism is concerned. I know that guy that wrote the
  8. ROF fractals.
  9.  
  10. It would be fun to add a chapter in the sequel to FOF that shows how to do 3D
  11. landscape generation following the Comanche approach, that is prestoring
  12. height info and finding a way to reconstruct the original terrain. But before
  13. that I would like to see FOF take on some simple polygon mountains and
  14. terrain like the kind used in Falcon 3. Then I'd like to see some bit mapped
  15. mountains. 
  16.  
  17. Speaking of wish lists, here is mine:
  18.  
  19. 1. Outside the cockpit views.
  20. 2. More items on the ground and an editor for building your own gound
  21. objects. 
  22. 3. Enemy planes, wingman, and engagement.
  23. 4. More weapons and a weapons editor.
  24.  
  25. Anybody got another other ideas/requests/wishes?
  26.  
  27. Mitch
  28. ...........................................................................
  29.  
  30. Fm: Chris Lampton [GAMPUB] 76711,301           # 332757 
  31. To: Mitchell Waite 75146,3515 (X)              Date: 13-Apr-93  12:35:46
  32.  
  33. RESCUE ON FRACTALUS was awfully impressive in its day. Nobody'd ever done
  34. anything like that before. Of course, that was the better part of a decade
  35. ago and it was written on an 8-bit machine, so it looks kinda crude now. But
  36. it demonstrated basic principles that are still being explored by programmers
  37. in the 1990s!
  38.  
  39. There's no question that the FOF sequel should include COMANCHE-style
  40. landscape representation, though I suspect it will require more than one
  41. chapter. And, yes, there should be more done with polygon mountains. This
  42. won't require too much new technology over the first FOF, just more work on
  43. the scenery database. What's really needed is the program I never quite got
  44. working in FOF, to generate complex mountain shapes. I've got some new ideas
  45. about that one, so maybe this time I'll get it up and running. And an editor
  46. for designing ground objects would be great to include, though simply
  47. designing a user interface for such a program is a subject worthy of its own
  48. book! 
  49.  
  50. My wish list also includes polygon smoothing, using either Gouraud or Phong
  51. shading (or modified versions thereof), a subject I suspect there'll be great
  52. enthusiasm for among the crowd in this forum. Gradient-fill horizons would
  53. also be fun to play around with. Although I discuss horizons at some length
  54. in FOF, adding the gradient would add an interesting and exciting new level
  55. of complexity to an already complicated task.
  56.  
  57. Bitmaps are another topic that can be covered at _incredible_ length! In
  58. fact, there could be a completely separate book in that one (though I've got
  59. dibs on writing it!). STRIKE COMMANDER looks like it's about to introduce a
  60. whole battery of new techniques, many of them having to do with rotated
  61. bitmaps. Most importantly, there's an entire new genre of bitmapped dungeon
  62. games now attaining unbelievable popularity -- ULTIMA UNDERWORLD, WOLFENSTEIN
  63. 3D plus several upcoming shareware and commercial games that are going to
  64. blow people's socks off! The excitement over these games has been quite
  65. palpable among the game designers in this section. I'd love to do a
  66. _parallel_ sequel to FOF concerning these things. (Perhaps it could be called
  67. Dungeons of Dread?) This would allow me to discuss the various kinds of
  68. texture mapping -- vertical post, three-dimensional -- and their application
  69. to interior maze exploration games. And I've got an idea for a _great_
  70. chapter on monster animations! <g> 
  71.  
  72. As for the FOF sequel, there could be an entire _section_ covering the
  73. airplanes themselves -- external views of planes, combat systems, multiple
  74. airplanes, aerial combat sequences. And perhaps, instead of modelling a
  75. simple propeller driven plane as in FOF, the sequel could concentrate on
  76. jets. A HUD could be added to the cockpit view, with the ability to lock onto
  77. targets, follow them on radar, launch missiles, etc.
  78.  
  79. Other possible topics: Mode X animation, SVGA animation, Truecolor (24-bit)
  80. animation, VESA programming, use of XMS and EMS to store data, and (if
  81. Borland updates their compiler to handle it) full 386 protected mode
  82. programming. 
  83.  
  84. Yeesh, what am I getting myself into?! <g>
  85.  
  86. --Chris
  87. ...........................................................................
  88.  
  89. Fm: Chris Lampton [GAMPUB] 76711,301           # 333188 
  90. To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 13-Apr-93  22:14:17
  91.  
  92. The key point about the raycasting is that the scenery is strictly
  93. two-dimensional; only height values for terrain "points" (the grid elements)
  94. are stored. So when you look across the terrain at an angle, what you see is
  95. the differences in heights between terrain points, as vertical lines. As a
  96. ray crosses a straight-line sequence of these terrain points, a vertical line
  97. is drawn each time in the current screen column to represent the difference
  98. in height (the "rise," if you will) between each terrain point and the one
  99. beyond it. Perhaps a different color could be used for the top pixel of each
  100. "rise" to differentiate it from the side of the rise, to give a light-sourced
  101. effect. 
  102.  
  103. This is hard to explain without a picture. Taking a good look at the COMANCHE
  104. screen helps. Have you played it? There's a demo over in GAMAPUB LIB 16 if
  105. you haven't. Search on the keywords NOVALOGIC or COMANCHE.
  106.  
  107. Yes, it would look pretty nifty in 320x200x32K, but not enough people have it
  108. yet to make it viable for a game. Heck, the graphics board I've got in my
  109. machine currently can do 320x200x16M, which would look _really_ neat! (And
  110. would be _really_ slow! <g>)
  111.  
  112. --Chris
  113. ...........................................................................
  114.  
  115. Fm: John Dlugosz [ViewPoint] 70007,4657        # 333277 
  116. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 14-Apr-93  00:25:34
  117.  
  118. <<So when you look across the terrain at an angle, what you see is the
  119. differences in heights between terrain points, as vertical lines.>> So what
  120. _color_ is it?  That is, what's the surface normal?  Looking at a nest of
  121. vertical poles will give me a solid blank wall of uniform color.
  122.  
  123. <<slow>> manipulating 16-bit pixels is _faster_ than 8-bit pixels if done one
  124. at a time.  I would buffer strips and write a whole pixarray at once, so it
  125. does translate to a speed difference.  But I don't think the extra writes are
  126. significant compared to the other processing.
  127.  
  128. I'm thinking of a demo and example, not a full game!  If it makes you dizzy,
  129. so much the better <g>.
  130.  
  131. I kind of like my tent-pole ideas.  Wonder how fast I can get it?
  132.  
  133. How about higer res than 320x200?  Even if not good for realtime animation,
  134. it means I can redislay the surface I'm viewing from any angle in a small
  135. fraction of the time it takes with the method used in SURFACE/SHOW that I
  136. think I sent you.
  137.  
  138. For each point in the field, I need a height value and 6 colors.  Be lavish
  139. and figure 13 bytes each.  That means 400K would be good for 31K points, or
  140. 177 points square.  The mountain in my SURFACE program is 128 square.  Sounds
  141. doable. 
  142. --John
  143. ...........................................................................
  144.  
  145. Fm: Chris Lampton [GAMPUB] 76711,301           # 333456 
  146. To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 14-Apr-93  10:06:08
  147.  
  148. I'll have to go back and reinstall the COMANCHE demo to think about the color
  149. business. I assume that the colors are determined in advance, since the
  150. terrain never moves and therefore never has to be re-lightsourced (unless the
  151. sun is assumed to be moving through the sky, which isn't really necessary).
  152. Thus, shadow and light effects could be precalculated and stored in the
  153. array, if there's room. Some "vertical poles" will be dark, some light, most
  154. somewhere in between. A hell of a lot of work to precalculate and store, yes,
  155. but the effect should be worth it. Of course, I already see the flaw in this:
  156. what if a pole is half in light, half in shadow? How do you store that? Like
  157. I said, I'd better go reinstall COMANCHE (as soon as my taxes are done <g>).
  158.  
  159. Try to hold your res down to 640x480, because that's all my current monitor
  160. can handle. BTW, I was unable to run that fractal mountain demo you sent me,
  161. because it wants to run at a higher res. Is there a command line switch I can
  162. use to get it down to 640x480? (If all you guys will keep buying copies of
  163. FLIGHTS OF FANTASY, I promise to invest a chunk of the royalties in an SVGA
  164. monitor! <g>) 
  165.  
  166. --Chris
  167. ...........................................................................
  168.  
  169. Fm: Mark Betz/Ass't SysOp 76605,2346           # 333013 
  170. To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 13-Apr-93  19:38:20
  171.  
  172. I've been thinking about raycasting, too. The basic cut of it that I
  173. understand is that you cast a ray from the POV to each pixel of the 320
  174. vertical columns (or whatever number is visible), stopping at the first
  175. location in the x-z plane that has a feature in position to occult the ray.
  176. You then draw a pixel at that point in the appropriate color. Height data is
  177. a 2d array of y offsets. I imagine some sort of highly optimized 3D
  178. Bresenhams could be used to cast the ray.
  179.  
  180.                                                 --Mark
  181. ...........................................................................
  182.  
  183. Fm: John Dlugosz [ViewPoint] 70007,4657        # 333173 
  184. To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 13-Apr-93  21:58:58
  185.  
  186. No, you will not cast from a single POINT of view through each pixel in the
  187. screen.  Rather, you will make all the rays paralell, not meeting at a point,
  188. passing through each pixel.
  189.  
  190. Anyway, imagine a bunch of telephone-pole-like objects of various lengths.
  191. The top surface is the x-z point and the pole is elevating it in y.  Your ray
  192. hits the side of the pole, not the top.  What color to make it?  It just
  193. doesn't make sence.
  194.  
  195. Instead, stretch a rubber sheet over the poles and nail it down in the middle
  196. of each one.  this causes a bunch of flat triangles to appear.  Each one of
  197. these can be colored ahead of time.  _this_ is what I want to intersect with.
  198.  
  199. So, back to the first pole image.  There are 6 triangles meeting at the top
  200. of the pole.  Based on which pole I hit and the direction I was coming from,
  201. I identify the triangle.
  202.  
  203. Hmm, since the direction is always the same, 6 colors per pole is enough, and I
  204. figure out which one ahead of time and use it for all 64,000 casts. That's
  205. it!! 
  206.  
  207. Thanks, I understand it much better now.
  208.  
  209. --John
  210. ...........................................................................
  211.  
  212. Fm: shmuel cohen 70431,1617                    # 332968 
  213. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 13-Apr-93  18:34:24
  214.  
  215. Good job!  I'll go back through the joystick stuff - but probably not tonight -
  216. I just spent the day on Uncle Sam's stuff - and boy did I take it up the ol'
  217. !@#$@.   Anyway, after I recover from my comatose state I'll dig into the
  218. joystick stuff.
  219.  
  220. BTW, one last optimization on the Pcx::Display routine - add the screen.h
  221. header file to the pcxclass.h and
  222. then replace the Pcx::Display() function with this:
  223.  
  224. void Pcx::Display()
  225. {
  226.    blitscreen ( image );
  227. }
  228.  
  229. By using Mark's blitscreen, we get a further improvement of 10% on my
  230. machine, probably more on others.
  231.  
  232. This process might also make an interesting sidebar in a future addition -
  233. especially if you have another section on optimizations - going from you For
  234. loop to memove to Mark's asm routine.
  235. ...........................................................................
  236.  
  237. Fm: Mark Phillips 73167,3216                   # 332662 
  238. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 13-Apr-93  10:05:26
  239.  
  240. Chris,
  241.  
  242.  I am slowly working my way through FoF. First, Chapter 2 is the clearest
  243. explanation of 3d math I've ever seen. Perfection!
  244.  
  245.  I found some typo's though. In ch. 3, at the top of pg. 73 you say the
  246. function number of a video BIOS call goes in AL, and the code fragment says
  247. the same thing. Listing 3-1 has it correct, with the function number in AH.
  248. Pg. 75 has a C code fragment with 13h in it, shouldn't it be 0x13? The text
  249. at the top of pg. 82 has the same problem as pg. 73, AH and AL are reversed.
  250. In listing 3-3 the comment doesn't match the code, the code is hardwired for
  251. all 256 palettes while the comment indicates it should pass parms for
  252. FIRSTREG and NUMREGS. Finally, (g) the Table 5-1 says the joystick read
  253. function is 16h, should be 15h.
  254.  
  255.  All minor problems. I'm a real beginner at C (I'm trying to convert FoF to
  256. PowerBasic), so any code typos were certainly missed by me.
  257.  
  258.  Thanks again for the great book!
  259.  
  260. mjp
  261. ...........................................................................
  262.  
  263. Fm: David K. Morton 70750,1105                 # 333069 
  264. To:  76711,301 (X)                             Date: 13-Apr-93  20:15:07
  265.  
  266. Chris:  I bought the book on Flights of Fantasy last weekend and decided to
  267. try to compile it on my machine.  The Make facility stoped at the file
  268. drawpc.cpp. Is this in the book someplace or on the disk?  I could not find
  269. it in or on either.  Could this be in the library.  Thanks in advance. Dave
  270. Morton 70750,1105.
  271. ...........................................................................
  272.  
  273. Fm: Chris Lampton [GAMPUB] 76711,301           # 333145 
  274. To: David K. Morton 70750,1105 (X)             Date: 13-Apr-93  21:28:50
  275.  
  276. Looks like I renamed a file without updating the makefile. (I was using the
  277. Borland PRJ file myself.) Best way to fix this is to edit the makefile so
  278. that DRAWPC.CPP will read DRAWPOLY.CPP instead. If that doesn't work, get
  279. back to me right away, and I can probably suggest some alternative fixes.
  280.  
  281. Thanks for catching that! Yet another change for the next printing!
  282.  
  283. --Chris
  284. ...........................................................................
  285.  
  286. Fm: Chris Lampton [GAMPUB] 76711,301           # 333481 
  287. To: All                                        Date: 14-Apr-93  11:12:39
  288.  
  289. For those of you who have purchased my book FLIGHTS OF FANTASY, I just wanted
  290. to mention that a bug has been reported in the program OPTDEMO.EXE, which
  291. illustrates optimization concepts discussed in Chapter Nine. This is the
  292. program that rotates shaded cubes and pyramids. Although the rotation works
  293. just fine, the scaling functions (operated by the + and - keys) do not work.
  294. If you use them, the cube swells beyond the proportions of the viewport,
  295. trashing memory and locking up the machine. (Cute, right? <g>) This is a
  296. version control problem: The version that was _supposed_ to go into the book
  297. should have had the scaling functions disabled, since clipping code had not
  298. yet been introduced in the book at this point and could not be used to
  299. prevent memory from being clobbered.
  300.  
  301. The solution? Don't use the scaling controls! <g> I'll post another version
  302. shortly with these controls disabled.
  303.  
  304. For those who have not yet purchased the book, don't worry. This problem
  305. doesn't affect the flight simulator -- or any of the other programs in the
  306. book. But it creates quite a spectacular visual effect right before it
  307. crashes your machine! ;-)
  308.  
  309. Sorry about that one, folks!
  310. ...........................................................................
  311.  
  312. Fm: Hans Peter Rushworth 100031,473            # 337130 
  313. To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 18-Apr-93  21:09:25
  314.  
  315. >> I'm struck by the difference between the crystal clear bowl in which most
  316. flight sims operate, and the film footage I've seen. There's a atmospheric
  317. hazy quality to most of it that the sims haven't reproduced.
  318.  
  319. That's true, conversely, on clear, bright, sunny days (or when you're above
  320. the clouds) there is an intensity to the light that you cannot reproduce on
  321. film, or on a display screen (unless you have a projector and you look into
  322. the lenses!). Under these circumstances sunglasses are mandatory. It is
  323. virtually impossible to see another aircraft if it is flying "out of the
  324. sun". In fact it is most often VERY hard to see the other aircraft when it is
  325. below you against the ground. Let alone flying through cloud. It is also
  326. surprisingly difficult to pickout things like runways that are designed to be
  327. easily seen. 
  328.  
  329. It's no accident that excellent vision is a mandatory requirement for pilots,
  330. especially in the military.
  331.  
  332. Haze is a factor, but the sun, ground complexity and clouds are perhaps more
  333. significant, in my (limited) experience.
  334.  
  335. I'm not sure I would agree that speckle is an accurate model for haze or fog.
  336. Distant objects "become grey" and/or "lose spatial resolution", but they
  337. don't get "noisy" (like untuned TV), or do they? The "mirage" shimmering
  338. effect on hot days occurs only if you are close the ground (I think). 
  339.  
  340. Of course I don't mean to suggest the dithering or similar methods are not
  341. appropriate in solving problems in computer graphics.
  342.  
  343. Peter.
  344. ...........................................................................
  345.  
  346. Fm: rod lentz 71163,57                         # 337952 
  347. To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 20-Apr-93  01:16:44
  348.  
  349. >> integer sqrt()
  350.  
  351.     The integer sqrt() method I'm current using is based upon Newton's
  352. method of successive aproximations; in asm, it's the fastest I've
  353. tested yet for the 386+ cpu's.  I believe that two versions from me,
  354. and several others from other contributors went into the "wolf3d.thd"
  355. that was just u/l'ed.  If it's not in there & you want specifics, let
  356. me know & I'll send it over.
  357.  
  358. >> and distances via table trig
  359.  
  360.     My most frequent use of table trig so far is for calculating 2d
  361. distances without sqrt()s.  This is using a table of pre-calc'ed
  362. cos (atan ())'s.  The elements are currently stored as rationals
  363. (numer, denom), which can also be treated as vectors.  I'll probably
  364. change these over to fixed point soon.
  365.     I've just started adding a few more similar trig tables for
  366. some special uses.  I've got tables all over the place !
  367.  
  368.     BTW, tables are also great for _quickly_ doing simple image
  369. processing on "packed rgb pels" (mapping an rgb cube in 256 color
  370. mode).  Mixing, adding, &c.; although the memory overhead is quickly
  371. rising <g>.
  372. ...........................................................................
  373.  
  374. Fm: Hans Peter Rushworth 100031,473            # 337471 
  375. To: John Dlugosz [ViewPoint] 70007,4657 (X)    Date: 19-Apr-93  13:03:58
  376.  
  377. John,
  378.  
  379. >> I sent stuff that uses 256 color, and a mode13h driver.  This records my
  380. experiments.
  381.  
  382. Yes, got it (twice <g>), thanks.
  383.  
  384. I did some tests using your ideas in my own shading routines. It's very
  385. sucessful in removing the ring artifact where the difference between shades
  386. is very small (ie if you have a lot of shades), but with larger intensity
  387. differences it is less good (you then end up with wider, albeit unfocussed,
  388. rings). It seems that the diffusion depth between regions needs to be a
  389. function of the difference between available shades for a given surface.
  390.  
  391. I'll play with it a little more and see if I can get better results for this
  392. situation.
  393. ...........................................................................
  394.  
  395. Fm: Hans Peter Rushworth 100031,473            # 337526 
  396. To: Hans Peter Rushworth 100031,473 (X)        Date: 19-Apr-93  15:40:02
  397.  
  398. Ok, simply adding a small fixed amount of noise cures this problem. The
  399. amplitude of noise needs to be reduced for the surfaces that are rendered
  400. with a colour that has more palette shades allocated to it to prevent those
  401. surfaces looking noisy. In essence:
  402.  
  403.   pixel_intensity += (distinct_shades > 16) ? rand() & 3 : rand() & 7;
  404.  
  405. The results are surprisingly good, and let you get away with fewer shades
  406. (and hence giving you more free colours in your colour map).
  407.  
  408. Mark: If you want a SHADE update which has this dither option, just ask.
  409.  
  410. Peter.
  411. ...........................................................................
  412.  
  413. Fm: rod lentz 71163,57                         # 337538 
  414. To: Hans Peter Rushworth 100031,473 (X)        Date: 19-Apr-93  15:52:48
  415.  
  416.     John - I played with the sample; looks good !  Still looks a little
  417. slow for real-time, though.
  418.     In my experience, if you have enough [spatial] resolution, adding
  419. noise of +-1 target level does a good job of minimizing rings &
  420. similar artifacts.  +-0.5 probably gives a more technicly accurate
  421. dither, but subjectively I find less preferable.
  422.     Also, if you have enough spatial resolution, dithering _all_
  423. shades, even "pure" ones in the palette, looks good.  It gives a
  424. slightly pointilistic effect, but one I like.  If high enough res,
  425. spatial integration does a great job with this effect.
  426.     Let me dig around; if you want, I'll send out a copy of my
  427. "noise diffusion" dithering.
  428. ...........................................................................
  429.  
  430. Fm: Mark Betz/Ass't SysOp 76605,2346           # 337927 
  431. To: Mitchell Waite 75146,3515 (X)              Date: 20-Apr-93  00:41:43
  432.  
  433. I believe that is the problem, Mitch, yes. FoF was developed on machines with
  434. FPU's, and while it was tested on machines without them, it was not tested to a
  435. great enough extent that I could make a representation. I was afraid that the
  436. emulation would prove to be very slow, and sadly that fear has manifested
  437. itself in reality. The lesson is to implement your own fixed-point math and
  438. stay away from the emulator.
  439.  
  440.                                                         --Mark
  441. ...........................................................................
  442.  
  443. Fm: Mitchell Waite 75146,3515                  # 337888 
  444. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 19-Apr-93  23:43:37
  445.  
  446. How about this for scenery direction algorithms. Look at Gary Yost's 3D
  447. Studio IPAS routines, particularly Silicon Gardens' plants, trees, and other
  448. nature schrubs. They make plants and plants and terrain have a lot in common.
  449.  
  450. Another idea is to find some equations to simiulate wrinkles. Ding! I think
  451. POV Ray has a wrinkles function. I know it can generate a texture that goes
  452. inside an object. Perhaps one could use POV Ray to generate a large wrinkled
  453. bit map 2D image. Then a program could be written to process the color info
  454. to represent height. (Details could be drawn with POV Ray into the bit map in
  455. any size if you wanted zooming.) Then figure out how to get the viewers POV
  456. on the screen at 14 fps :)
  457. ...........................................................................
  458.  
  459. Fm: rod lentz 71163,57                         # 337978 
  460. To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 20-Apr-93  01:44:46
  461.  
  462.     It's a rare occasion I ever use the emulator.  For years, I've
  463. been jumping through hoops (as most others) to use int's, rationals
  464. and fixed points.  Now, it's so ingrained that I rarely use floats,
  465. even if the app isn't time critical & I know it will only be run on
  466. my (486dx) machine.
  467.     Also, I was once writing a tsr in msc, and discovered that my
  468. one use of floating point (addition only) caused the entire emulator
  469. to be included.  At about 11k, it was an awful lot of overkill for
  470. that little use, and I switched to fixedp.
  471.  
  472.          - Rod
  473. ...........................................................................
  474.  
  475. Fm: Chris Lampton [GAMPUB] 76711,301           # 338169 
  476. To: Mitchell Waite 75146,3515 (X)              Date: 20-Apr-93  11:31:53
  477.  
  478. Wrinkles would be yet another fractal feature (and probably as slow as the
  479. rest <g>). Does POV ray generate the wrinkles or is it working from a
  480. pre-existing bitmap? Sounds like it would be easier to get FRACTINT to
  481. generate something like that and work backwards from it. Best of all, I'll
  482. just look at the source code to both of'em and see what I can steal, er,
  483. learn from. ;-) 
  484. --Chris
  485. ...........................................................................
  486.  
  487. Fm: Chris Lampton [GAMPUB] 76711,301           # 347021 
  488. To: Ian Christie 70534,403                     Date: 03-May-93  14:16:52
  489.  
  490. There are some problems with three of the programs. WAITE.EXE _does_ cause a
  491. memory allocation error, OPTDEMO will crash if you use the scaling keys (+
  492. and -), and FOF.EXE locks up on a few machines, all fast 486s. I haven't
  493. heard of any problems with POLYDEMO.
  494.  
  495. In the first two cases, the problem is with clipping. Since polygon clipping
  496. hasn't been introduced at that point in the book, it's not used in those
  497. programs, and it's needed. <g> Unfortunately, I didn't trap out all cases
  498. where polygons could run off the virtual screen and trash memory. As for the
  499. FOF.EXE lock-up -- we aren't sure yet what causes it. Two possible clues: it
  500. only seems to happen on fast 486s without joysticks and/or gameports; and
  501. some people have reported that the problem clears up if they install the
  502. program a second time. Does your machine have a gameport? And have you tried
  503. reinstalling? If you do reinstall, I'd recommend clearing up a little extra
  504. disk space, in case it's some kind of out-of-memory error. How much free
  505. space do you have on that drive, BTW?
  506.  
  507. Any insights you may have as to what's causing the FOF.EXE lock-up would be
  508. appreciated, since we haven't been able to duplicate it. When we do, we're
  509. going to make a fixed version available. Thanks for the report!
  510.  
  511. --Chris
  512. ...........................................................................
  513.  
  514. Fm: Chris Lampton [GAMPUB] 76711,301           # 353865 
  515. To: Jeff Ross 71561,3161                       Date: 13-May-93  05:14:42
  516.  
  517. Jeff:
  518.  
  519. You're correct about everything except the bitmap compression. The cockpit
  520. bitmap is compressed only once, when it's initially loaded into memory, and
  521. is stored in a buffer. It remains compressed (without being recompressed) for
  522. as long as the program continues running. For each individual frame of the
  523. animation, a decompressed version of the bitmap is drawn over top of the 3D
  524. view, with the view showing through the transparent portions of the cockpit.
  525. (The decompression is performed by the Ctransput() function, described in
  526. Chapter Fifteen.) 
  527.  
  528. The reason that the cockpit is maintained in compressed form is that it can
  529. be moved to the video display much faster that way, without transparency
  530. checking (and transparent pixels can simply be skipped altogether). In an
  531. earlier version of the code, we maintained the bitmap in uncompressed form
  532. and it ran _unbelievably_ slow! Compressing the cockpit bitmap more than
  533. quadrupled our frame rate, if I recall correctly.
  534.  
  535. --Chris
  536. ...........................................................................
  537.  
  538. Fm: Rasputin 71005,2524                        # 358678 
  539. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 19-May-93  23:52:44
  540.  
  541. Chris, after several people in this forum recommending your book to me (FOF), I
  542. finally got it (It was a birthday present from my mom!). anyways, I was
  543. pondering the Idea of the Z buffer, and came up with a theoretical solution
  544. to make it faster, and possibly faster than the painter's algorythm (sp?)
  545. anyways, it goes like this ... Instead of storing the Z for each point, store
  546. the Z for a run of points... presumably in the polygon drawing routine... and
  547. don't actually plot those points at that time, store them in an array of line
  548. runs... when a lower Z comes along, you could perform surgery on the array as
  549. necessary to reflect the changes(leaving the pixels that weren't covered, and
  550. modifying longer runs that were covered only in the middle. then when it
  551. actually came time to draw the runs, you could compare them with the array of
  552. runs that you drew for the previous screen, tand avoid redrawing long runs of
  553. pixels, thereby bypassing the need to erase the old screen, or draw large
  554. areas of the screen that didn't change...  I know that my explanation of the
  555. theory I have formulated is kind of sketchy... do you get where I'm coming
  556. from? any and all responces welcome.
  557.  
  558.                                 Dan Kelly.
  559. ...........................................................................
  560.  
  561. Fm: Chris Lampton [GAMPUB] 76711,301           # 359234 
  562. To: Rasputin 71005,2524                        Date: 21-May-93  00:53:08
  563.  
  564. Dan:
  565.  
  566. Interesting idea, but I'm having some trouble visualizing how the Z runs
  567. would be stored. I assume they'd need to be horizontal runs, since that would
  568. optimize the actual drawing of the pixels when the time came to do so. But
  569. that means one end of the run could have a different Z value from the other,
  570. since there's no guarantee that the run will be parallel to the display
  571. plane. So the structure would need to be designed to store at least two Z
  572. values for each run in a way that would allow fast comparisons between
  573. overlapping runs. The main problem might be quick identification of
  574. overlapping runs -- i.e. how do you rapidly determine which old run to
  575. compare a new run against? Perhaps with a binary search of some kind? If you
  576. could find a way to organize the structure efficiently (as some kind of
  577. tree?), it might be more accurate than an unaugmented depth sort and faster
  578. than a complete Z buffer. Could be worth thinking about in more detail. 
  579.  
  580. Come to think of it, there's a hidden surface removal technique called the
  581. scan-line method that I ran across while writing FLIGHTS OF FANTASY that's
  582. similar to what you're describing (or at least to the way I'm visualizing
  583. it). I haven't really studied it and can't pretend that I understand the
  584. details, but if you've got access to a copy of Hearn and Baker's COMPUTER
  585. GRAPHICS (my favorite reference when I was writing FOF), it's discussed on
  586. pages 264-265. It involves performing a separate sort of polygon edges for
  587. each scan line in the viewport. My superficial impression is that it would be
  588. too slow for realtime animation on current generation processors, but might
  589. be similar to the way your Z run method would work in practice and could be
  590. superior to the Z buffer in some circumstances. You might want to check it
  591. out to see if it gives you some ideas.
  592.  
  593. --Chris
  594. ...........................................................................
  595.  
  596. Fm: Chris Lampton [GAMPUB] 76711,301           # 363026 
  597. To: All                                        Date: 26-May-93  04:56:35
  598.  
  599. Those of you have encountered the mysterious lock-up problem with the FOF.EXE
  600. flight simulator that comes with my book FLIGHTS OF FANTASY (where the sim
  601. locks up immediately after the opening title screen) will be happy to know
  602. that Mark Betz and I located the source of the problem last night. I'll be
  603. uploading a fix as soon as Mitch Waite and I decide on what form the fix
  604. should take. For now, you can fix the problem yourself if you have the BC++
  605. compiler (or TC++ and TASM). In module AIRCRAFT.CPP, change line 544 from
  606.  
  607.   loopTime /= 1000;
  608.  
  609. to
  610.  
  611.   if (!(loopTime /= 1000)) loopTime = 1;
  612.  
  613. and recompile FOF.EXE.
  614.  
  615. This _should_ fix the problem. (It avoids a Divide by Zero error later in the
  616. code that apparently only occurs on fast machines without joysticks or sound
  617. boards to slow down the simulator's initial loop timing calculations.) If it
  618. _doesn't_ fix it, let me know right away. Thanks!
  619. ...........................................................................
  620.  
  621. Fm: Chris Lampton [GAMPUB] 76711,301           # 365830 
  622. To: Ian Christie 70534,403                     Date: 30-May-93  21:56:29
  623.  
  624. The fix for the FLIGHTS OF FANTASY lock-up bug that occurs on some fast
  625. machines is to change line 544 of AIRCRAFT.CPP from
  626.  
  627.   loopTime /= 1000;
  628.  
  629. to
  630.  
  631.   if (!(loopTime /= 1000)) loopTime = 1;
  632.  
  633. and recompile FOF.EXE.
  634.  
  635. Let me know if that works for you.
  636.  
  637. --Chris
  638. ...........................................................................
  639.  
  640. Fm: Paul Whittemore 72007,3305                 # 367865 
  641. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 02-Jun-93  19:45:16
  642.  
  643. Just found my first FOF bug...  Try pulling back until you're inverted and
  644. look out either side.  As you cross the 90 degree mark you'll see a weird
  645. 'flash'. 
  646.  
  647. But even if you miss this, while flying inverted, pull back.  This should
  648. send you toward the ground.  It does, but in the side views, the pitch is
  649. reversed so it *looks* like you're climbing inverted.  Eventually, you'll
  650. crash, but the view indicates climbing.
  651.  
  652. Got some more FOF reading to do or I'd find the offending line right away.
  653. (Don't wanna get dirty ... yet.)
  654.  
  655. Paul
  656. ...........................................................................
  657.  
  658. Fm: Chris Lampton [GAMPUB] 76711,301           # 368104 
  659. To: Paul Whittemore 72007,3305 (X)             Date: 03-Jun-93  03:42:38
  660.  
  661. I'm familiar with the "flash" bug. I chased it for a while but never caught
  662. it. Finally, I just left it in. Ultimately, the problem has to be in the
  663. draw_horizon() function, though it might be triggered in turn by something
  664. earlier in the code. That's where to start looking, though. That function,
  665. which draws the sky and ground background colors, was the second most
  666. difficult part of the code to write. (Hidden surface removal was the
  667. hardest.) Took at least two weeks to get that one function working properly.
  668. And still, under certain conditions, the sky and ground magically reverse.
  669. (That's what causes the flash.) It only happens for a single frame at a very
  670. few orientations and I never was able to figure out why. If you do, be sure
  671. and let me know.  
  672.  
  673. I hadn't noticed that problem with the side views. I remember how crazy Mark
  674. and I went figuring how to calculate the side views, so obviously we missed
  675. something. I'll try that and take a look. Once again, if you find the cause,
  676. let me know!
  677.  
  678. --Chris
  679. ...........................................................................
  680.  
  681. Fm: Hans Peter Rushworth 100031,473            # 368718 
  682. To: Mark Betz/Ass't SysOp 76605,2346 (X)       Date: 04-Jun-93  00:42:42
  683.  
  684. Mark,
  685.  
  686. >> Does it handle the view orientation correctly from all angles?
  687.  
  688. Yes, It works right off the rotation transform matrix, so whatever
  689. combination of heading/pitch/bank/yaw etc is automatically catered for. It
  690. still has the obligatory 16-way switch, of course. <g>
  691.  
  692. I'll see if it's in a state to post, if not I will email it...
  693.  
  694. Peter.
  695. ...........................................................................
  696.  
  697. Fm: Chris Lampton [GAMPUB] 76711,301           # 368686 
  698. To: Hans Peter Rushworth 100031,473 (X)        Date: 03-Jun-93  23:55:24
  699.  
  700. Actually, I would kinda like to see that horizon routine, if you'd still like
  701. to send it on. It could be useful to see how you approached the problem,
  702. assuming you've made some changes from last summer's version.
  703.  
  704. --Chris
  705. ...........................................................................
  706.  
  707. Fm: Hans Peter Rushworth 100031,473            # 368908 
  708. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 04-Jun-93  11:11:15
  709.  
  710. Chris,
  711.  
  712. I'll email you the full version, the trick is how to calculate window
  713. intercepts and decide upness. The following is a brief explanation of how it
  714. works, that I wrote at the time to our project supervisor. You can tell from
  715. this that I was extremely pleased with myself. <g>
  716.  
  717. ____________
  718. (28-November):
  719.  
  720. Using the equation for the horizon plane and plugging the values for the
  721. window edge vectors into it will give a unique solution for the window
  722. intercepts. The equation of the horizon plane comes directly from the plane
  723. normal, which is the 3rd column in the CTM. For Example, after some
  724. re-arrangement, the equation that gives the Y value of the right window edge
  725. intercept (when valid) is simply
  726.  
  727.  -((a + c) * height of window)/b) where [a] is the 3rd column of the CTM.
  728.                                         [b]
  729.                                         [c]
  730.  
  731. (if b is zero, it means that the horizon is outside the window, you test
  732. for this first obviously).
  733.  
  734. The other intercepts are similar.
  735.  
  736. Whats more, the question of "up" is solved by examining the sign of just one
  737. co-efficient in the matrix. (actually there is one case where you need to
  738. distinguish left from right, which just uses a different co-efficient of the
  739. matrix).
  740.  
  741. When I looked at this first I thought it was so simple it could NEVER work.
  742.  
  743. Surprise surprise. I can now calculate the intercepts of the horizon with
  744. the window edges for **_ANY_** orientation DIRECT from the CTM with ZOOM and
  745. SIZE/SHAPE taken into account In FOUR LINES of code. No trigonometry, mammoth
  746. overloaded behind your back matrix operations either. I am amazed. To think
  747. that I slaved for hours over trig methods and couldn't get it to work
  748. before, when this method is so direct and simple.
  749.  
  750. So anyway, the horizon works now.
  751. __________
  752.  
  753. Peter.
  754. ...........................................................................
  755.  
  756. Fm: Jeff Ross 71561,3161                       # 368063 
  757. To: Chris Lampton 76711,301 (X)                Date: 03-Jun-93  01:14:34
  758.  
  759. Chris,
  760.         Help.  I've tried several times to change the NUMBER_OF_DEGREES in
  761. the SIN/COS tables but have had no luck.  Generated 360 and 300 degree tables
  762. using makesine.cpp and then incorporated them into the project. All rotations
  763. are very jerky and unusable.
  764.         Thought the problem might have been in the mapangles routine in
  765. DrawHorizon, but, that didn't help.  For instance; with either of these new
  766. tables and rotating around the y axis (yaw) it will move for roughly 2-3
  767. degrees and then jump back, then if I keep pressing the key it will suddenly
  768. jump a whole bunch of degrees in that direction.
  769.         Do you think it may be a problem in actually generating the tables in
  770. Makesine.cpp? It seems pretty straight forward.  Perhaps in the Fixed-point
  771. usage?  I'm new to this 'Fixed-point' stuff so I could be missing something
  772. here. I realize it's probably something very minor/obvious but I cant' seem
  773. to see it.  I figure you had a reason for 256 degrees and maybe you could
  774. steer me in the right direction.
  775.  
  776.  
  777. As always, thanks
  778. Jeff
  779. ...........................................................................
  780.  
  781. Fm: Chris Lampton [GAMPUB] 76711,301           # 368088 
  782. To: Jeff Ross 71561,3161 (X)                   Date: 03-Jun-93  02:24:43
  783.  
  784. I was afraid of that. I never tried changing the number of degrees myself, so I
  785. really don't know if it could be done that easily or not. As I said in an
  786. earlier note, I may have assumed the 256 degree system somewhere in the code.
  787. I'll take a look through it and see if I can locate the assumption. It's
  788. probably in the view system somewhere, since Mark uses a different rotation
  789. system altogether in the flight model. Might just be a matter of making
  790. simple changes to the code. I'll get back to you on it.
  791.  
  792. --Chris
  793. ...........................................................................
  794.  
  795. Fm: Chris Lampton [GAMPUB] 76711,301           # 368101 
  796. To: Jeff Ross 71561,3161 (X)                   Date: 03-Jun-93  03:42:23
  797.  
  798. Okay, I think I may have found the problem. It's not in the FOF source code,
  799. but in MAKESINE.CPP, in the lines that write the SIN and COS macro
  800. definitions to the header file. These macros return a value from the sine and
  801. cosine arrays declared in FIX.CPP, first ANDing the array index with the
  802. NUMBER_OF_DEGREES minus one. (This is a fast way of getting the index modulo
  803. the number of degrees, as long as the number of degrees is a power of two.)
  804. I've hardcoded a 255 here. Rewrite this so that it will AND the index with
  805. the value of NUMBER_OF_DEGREES minus one. And be sure the new number of
  806. degrees that you choose is also a power of two (i.e. 512, 1024, 2048, etc.).
  807.  
  808. If this is confusing, let me know, and I'll send you specific code.
  809.  
  810. --Chris
  811. ...........................................................................
  812.  
  813. Fm: Jeff Ross 71561,3161                       # 368569 
  814. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 03-Jun-93  21:33:13
  815.  
  816. Chris,
  817.       Okay! Great! I thought it might have been in Makesine.cpp but it all
  818.       looked fairly straight forward to me. I guess I didn't look very
  819.       hard since it was a short routine.
  820.  
  821.       So, if I get you:
  822.  
  823.       Change ... const NUMBER_OF_DEGREES = 1024 // for example 1024 degrees
  824.  
  825.       Change ...cos_table[ABS(X)&1023]...
  826.              ...sin_table[ABS(X)&1023]...
  827.  
  828.       I'll try this out probably friday and let you know. Also, I'm
  829.       basically, so far, using the book as defined in chapt 15, interfacing
  830.       the View system. No code for flight model etc since I'm going in a
  831.       different direction here.  Have noticed that when I translate my
  832.       position beyond a certain point I seem to 'wrap' back around in the
  833.       world database.  Doing a straight increment of the curview.copx/y/z
  834.       values until I get my flight model hacked out. Haven't had a chance to
  835.       dig into this yet but before I do, is that the way it was intended?
  836.       The version I'm running uses your code as is, no mods at all, and the
  837.       world database that came with it "FOF2.WLD". Didn't see any mention of
  838.       this in the text.
  839.  
  840. Again, many, many thanks.  I'll get back to ya, Jeff
  841.  
  842. PS: Must thank you again for writing the book! As I've said before I've been
  843. trying to write a flight sim since I created my first "hello world!" program
  844. n QBasic.  You've saved me probably 6 months of work.  My only problem now is
  845. that a little information is becoming dangerous. I find I spend so much time
  846. coming up with algorithms and ideas for features (since I now have an
  847. "engine" for showing them) that I have a tuff time sitting down and putting
  848. the whole thing toghther!  This is fasinating to me. 
  849. ...........................................................................
  850.  
  851. Fm: Chris Lampton [GAMPUB] 76711,301           # 369081 
  852. To: Jeff Ross 71561,3161                       Date: 04-Jun-93  17:16:57
  853.  
  854. Yes, that's exactly what you need to do to change the number of degrees. (I
  855. see from your next note that you got it working, but I was too tired
  856. yesterday to respond to most of my messages so I'm responding to the earlier
  857. one instead. <g>) The wraparound is discussed in the Appendix and in the
  858. README file on the disk. It results from the fixed point routines, which only
  859. allow 14 bits precision to the left of the decimal point. Hence, there's an
  860. automatic coordinate wrap at position 16384 on any axis. If you want to
  861. rewrite the fixed point as a function or overloaded operator using 386
  862. registers, you can improve this considerably. There would still be limits. A
  863. commercial sim would load a new database before wrap occurs, but FOF.EXE
  864. isn't that sophisticated. 
  865. --Chris
  866. ...........................................................................
  867.  
  868. Fm: Paul Whittemore 72007,3305                 # 369269 
  869. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 04-Jun-93  22:24:24
  870.  
  871. Although I said I was going to finish the book first, I spent some time last
  872. night looking at the horizon problem with inverted side views.  (Since I
  873. haven't gotten to the corresponding chapter of the manual yet, you can take
  874. the following with a hunk o' salt.)
  875.  
  876. I don't think the problem is in the display_horizon method.  I think it's in
  877. the caller (display).  In fact, it may be a more general problem related to
  878. the inverted sign of Y coordinates.  And I think the horizon flash is related
  879. to this problem, and may even be the same one...  (Just a feeling.)
  880.  
  881. The view is fine, except that the slope of the horizon needs to be negated in
  882. the case of an inverted side view.  I tried forcing this, but realized the
  883. *objects* were also moving in the wrong Y direction.  (With the correct
  884. horizon, mountains would fly up into the air at the -angle that the ground
  885. was moving away.  Since the problem is not limited to the horizon, it's not
  886. *really* in draw_horizon. 
  887.  
  888. I don't know about the world/view system yet to take it any further, yet. And
  889. I wanna finish the book first, but I'll keep you posted...
  890.  
  891. Paul
  892. ...........................................................................
  893.  
  894. Fm: Chris Lampton [GAMPUB] 76711,301           # 369353 
  895. To: Paul Whittemore 72007,3305 (X)             Date: 05-Jun-93  00:33:55
  896.  
  897. No, I wouldn't expect to find the side view problem in draw_horizon() either,
  898. though I'm pretty sure that's the place to look for the flash problem. I'd be
  899. surprised if the two problems were related, though I could be wrong. (It's
  900. been a while since I wrote this stuff, after all.)
  901.  
  902. The best place to look for the side view problem is in the ViewShift()
  903. function. (See pages 524-525 in the book.) This is where we calculate the
  904. change in view angle for views other than straight ahead on the viewer's
  905. local z axis. Mark and I passed this function back and forth between
  906. ourselves a couple of times before we got it to work properly -- and we may
  907. still have missed some special cases. Check it out and see if you can see
  908. what we might have missed. It always helps to have fresh eyes look at the
  909. code. The case statement on page 525 cycles through the right, back and left
  910. views -- or is it the other way around? Hey, Mark!
  911. ...........................................................................
  912.  
  913. Fm: Chris Lampton [GAMPUB] 76711,301           # 372824 
  914. To: Paul Y. Chong 72762,2775                   Date: 10-Jun-93  01:17:04
  915.  
  916. Paul:
  917.  
  918. The FOF lock-up problem is triggered by a divide-by-zero error in module
  919. AIRCRAFT.CPP. It only occurs on fast machines, usually without a sound board
  920. and/or joystick to slow things down, which is why we missed it when putting
  921. the program together. If you've got the BC++ compiler you can fix it with a
  922. simple change to the code. Change line 544 of AIRCRAFT.CPP from
  923.  
  924.   loopTime /= 1000;
  925.  
  926. to
  927.  
  928.   if (!(loopTime/=1000)) loopTime = 1;
  929.  
  930. Let me know if that works. Good luck!
  931.  
  932. --Chris
  933. ...........................................................................
  934.  
  935. Fm: Paul Whittemore 72007,3305                 # 376168 
  936. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 14-Jun-93  18:57:59
  937.  
  938. I noticed some minor improvements: like the blitting was done 32-bits at a
  939. time (STOSD rather than STOSW) and I used incremental offsets in one loop
  940. (from Ch. 9) rather than multiplication.  (Things like that.)
  941.  
  942. BTW:
  943. I've more or less decided to do a *new* flight sim since I don't want to have
  944. to worry about legalities and other people's priorities, but one heck of a
  945. lot of the effort could be applied to FOF as well.  A complete 386 assembler
  946. fixed point library, network/modem support, external views, enemy planes,
  947. weapons, other moving objects (e.g. ground vehicles), variable altitude
  948. ground level, textured ground and my potential plan for bitmap-wrapped
  949. objects.  It could all be added to FOF as it becomes available without
  950. compromising my project (if it ever materializes).
  951. ...........................................................................
  952.  
  953. Fm: Paul Whittemore 72007,3305                 # 378921 
  954. To: LYNN L. HOWARD 71054,3050                  Date: 18-Jun-93  20:27:43
  955.  
  956. I tried recompiling the FOF source with -3 and my times dropped from
  957. 44 ms/f to between 36 and 39 ms/f.  I've written the necessary 386 32-bit
  958. fixed point routines, except for division.  (The book says only addition,
  959. subtraction and multiplication are necessary, but the source says
  960. otherwise.)  There are several initialization-time conversion functions
  961. required too, (and their also done), but I don't think they're needed per
  962. frame.  I'm going to take a stab at complete replacement for all the
  963. float/double and 16-bit fixed point math as soon as I get a chance.  I'll
  964. keep everyone informed of any performance gains I can get.
  965.  
  966. Thanx,
  967. Paul
  968. ...........................................................................
  969.  
  970. Fm: Andrew Amess 100141,1567                   # 378691 
  971. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 18-Jun-93  14:19:12
  972.  
  973. Hi, interested in your comments about buffer moves to VGA. I am currently
  974. writing games for the 386 and above which have 9 and more levels of parallax.
  975. I can upload some early demos, which look rather good.
  976. Anyway, about block moves, I have an idea and tried it out but didn't profile
  977. it, maybe it will ring some bells.
  978. I interleaved the move bytes to VGA code with move 0's to the system ram
  979. video buffer wondering if the processor would do the blit/clear loop quicker.
  980. A friend said yes it should because whilst the data is going down the bus you
  981. can be writing to system RAM. 
  982. Also, where can I find chit chat on optimising code as I need every cycle I
  983. can get my hands on at the minute.
  984. TIA.
  985. Chris Nurse (Using Andrew Amess account).
  986. ...........................................................................
  987.  
  988. Fm: Andrew Amess 100141,1567                   # 379165 
  989. To: Paul Whittemore 72007,3305 (X)             Date: 19-Jun-93  09:19:54
  990.  
  991. With the fixed point matrix multiplier, which I have also done in assembler:-
  992. To divide matrices do I just change my IMUL to a DIV etc...
  993. I have a rather nice assembler version which uses a macro and have unrolled
  994. the whole multiplication so you can get something in excess of 4500 complete
  995. operations per second; Is that good? I have nothing to compare against as I
  996. am not heavily into FOF code but the book has proved to be a gold mine since
  997. the day I got it! 
  998. ...........................................................................
  999.  
  1000. Fm: Paul Whittemore 72007,3305                 # 380186 
  1001. To: Andrew Amess 100141,1567                   Date: 20-Jun-93  20:53:04
  1002.  
  1003. > With the fixed point matrix multiplier, which I have also done in
  1004. > assembler:- To divide matrices do I just change my IMUL to a DIV etc...
  1005.  
  1006. With both the multiplication and division, it's not that simple if you don't
  1007. want to lose much accuracy.  With fixed point 32-bit division, the simple
  1008. division results in a complete loss of the fractional part (37/4= 9.000).
  1009. I'm planning on shifting the numerator left by as many places as there are
  1010. high zero bits (up to the number of bits to the right of the fixed point).
  1011. Then shift the denominator right for the difference.  This should maximize
  1012. precision without changing from a single division.  There are other methods
  1013. I'm looking at, too.  For multiplication, I'm looking at detecting overflow
  1014. and returning 0x7FFFFFFF (my 32-bit fixed point numbers are signed) which
  1015. should be good enough for 'fuzzy' accuracy like flight simulators.  I want
  1016. to prevent wrap while still allowing the large numbers to be multiplied
  1017. together.
  1018.  
  1019. I haven't had enough time yet to really look at it, but when I finish off
  1020. the routines, I'll post them for general use.  They're BC++ and TASM and
  1021. assume a 386+ for the 32-bit accuracy.
  1022.  
  1023. Regarding your routines: it doesn't sound like 32-bit accuracy if you can
  1024. implement them in a macro.  I don't have any idea about the performance
  1025. yet, so I can't say whether you numbers are good or not...
  1026.  
  1027. Paul
  1028. ...........................................................................
  1029.  
  1030. Fm: Eric Klein 72302,2731                      # 381056 
  1031. To: Mark Betz 76605,2346 (X)                   Date: 21-Jun-93  21:45:31
  1032.  
  1033. The FOF program from "Flight of Fantasy" book, hangs afters the initial
  1034. credit. I am using a local bus DX2-66 with "Diamond Stealth 24" local bus
  1035. video card.
  1036.  
  1037. Running FOF with "D"(debug) parameter gives a message "floating point
  1038. error:Domain" and then hangs.
  1039.  
  1040. Debuging through FOF it seems to crash in the image routines.
  1041.  
  1042. Any ideas of how to solve this problem?
  1043. Also where could I find the lastest source for FOF?
  1044.  
  1045. FOF runs fine in a compaq DX2-66 with Q-Vision video.
  1046. ...........................................................................
  1047.  
  1048. Fm: Chris Lampton [GAMPUB] 76711,301           # 381152 
  1049. To: Eric Klein 72302,2731 (X)                  Date: 21-Jun-93  23:29:48
  1050.  
  1051. Eric:
  1052.  
  1053. The FOF simulator sometimes locks up on fast 486s, especially if they lack a
  1054. SoundBlaster and/or joystick to slow down the code. If you've got BC++,
  1055. change line 544 in module AIRCRAFT.CPP from:
  1056.  
  1057.   loopTime /= 1000;
  1058.  
  1059. to:
  1060.  
  1061.   if (!(loopTime /=1000)) loopTime = 1;
  1062.  
  1063. and recompile. That should fix the problem.
  1064.  
  1065. I plan to upload the fixed EXE file to LIB 11 here within the next couple of
  1066. days.
  1067.  
  1068. --Chris
  1069. ...........................................................................
  1070.  
  1071. Fm: Mark Betz/Ass't SysOp 76605,2346           # 381476 
  1072. To: Eric Klein 72302,2731 (X)                  Date: 22-Jun-93  12:33:18
  1073.  
  1074. Hi, Eric. We had a problem with the program on very fast machines, often
  1075. those with neither a sound card or a joystick, which caused it to lock up
  1076. right after the opening screen with a FP domain error (divide by zero).
  1077. Essentially what is happening is that on these machines it takes less than 1
  1078. millisecond to get from the point in initialization where the timer is
  1079. started to the point in the flight model where it is read for the first time.
  1080. Since the elapsed time in microseconds is divided by 1000 to obtain
  1081. milliseconds, this situation results in an elapsed time in milliseconds of 0.
  1082. This is then used as a divisor in parts of the flight model, causing the
  1083. error. The author is getting ready to make the new version of the executable
  1084. available here in Game Design, but in the meantime the fix simply requires
  1085. making sure that loopTime cannot have a value of 0 on the first pass.
  1086.  
  1087.                                                         --Mark
  1088. ...........................................................................
  1089.  
  1090. Fm: Paul Whittemore 72007,3305                 # 382526 
  1091. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 23-Jun-93  19:36:54
  1092.  
  1093. > I plan to upload the fixed EXE file to LIB 11 here within the next couple
  1094. > of days.
  1095.  
  1096. You may want to consider uploading one recompiled with -3 also, since the
  1097. performance improvements are reasonable...  Just a thought.
  1098.  
  1099. Paul
  1100.  
  1101. P.S.  Still working on a complete replacement with 386-specific 32-bit
  1102.       fixed point, but I have a (work) deadline of Friday and I move on
  1103.       Tuesday so I've had to postpone it temporarily while I work like
  1104.       a dog...
  1105. ...........................................................................
  1106.  
  1107. Fm: Eric Klein 72302,2731                      # 382399 
  1108. To: Chris Lampton [GAMPUB] 76711,301 (X)       Date: 23-Jun-93  16:12:00
  1109.  
  1110. I recompile with your change and it works now.
  1111. Thanks for your quick response.
  1112.  
  1113.                 Eric
  1114. ...........................................................................
  1115.  
  1116.  
  1117.